1. Technical Field
The present invention relates in general to automatic coding and testing of object-oriented applications and in particular to automatic coding and testing of Internet applications requiring complex data structures and evolving data elements and properties. Still more particularly, the present invention relates to methods and data structures for optimizing automatic code generation and testing of object-oriented Internet applications.
2. Description of the Related Art
The need for Internet application development is proliferating at an exponential rate. Additional uses for Internet data communications are constantly evolving, including efforts to establish banking over the Internet such as have been undertaken by the consortium Integrion. Additionally, the complexity of Internet applications is rapidly increasing, prompted by increased functionality demands. In such complex programs, particularly those having many different data structures to develop, handcrafting code can be time consuming and error-prone, both for initial code generation and maintenance. Manual coding of complex data structures may be particularly cumbersome. However, there exist a number of obstacles to automatically generating and testing code for such applications, especially for object-oriented applications.
A number of object-oriented programming languages are commercially available which may be utilized to create objects for execution on a World Wide Web server or client. In some cases, such as Java objects, the objects may be sent directly to the client for execution. In other cases, such ac Javascript, the object executes on the server to customize the Web page which is transmitted to the client. Some applications may include many objects of these types, and each object may contain many properties. These properties may be added by the application, or may reflect data received from an external source such as a database.
Within the applications including objects with arbitrary properties, each object must have its own constructor which understands and initializes each property on the object. In circumstances in which the objects and their properties are structured around the format of external data, when the external data format changes or evolves, the objects and their properties must concurrently change to maintain compatibility. The amount of labor required to manually write and maintain object constructors for such objects as they evolve is remarkable.
An added level of complexity in automatically generating code for object-oriented applications arises in situations where some properties need to be grouped into secondary objects or "sub-objects." In such cases, the properties appear on the sub-object and the cub-object is itself a single property on the main object. A common example is parameters which include both a value and a format property. A sub-object for the parameter is created with the two properties, and the sub-object is attached as one property on the main object. Given that data structures in a database evolve during both product development and product life cycles, typically some fluctuation in property groups specified as sub-objects occurs. Generating code which assumes a certain set of sub-objects is likely to require recoding several times during the life span of a product.
Automatic testing of object-oriented Internet applications also requires that certain obstacles be overcome. A significant portion of testing of object-oriented product involves ensuring that the correct data values are assigned to the specific properties on these objects. In cases where the objects and their properties are structured around an evolving format of external data, as described above, test cases for objects must reflect external data format changes just as the objects and their properties must change. As with the labor required to manually write and maintain object constructors, the work required to manually maintain test cases for such objects as they evolve is also considerable.
Additionally, to perform unit test and some functional verification testing, appropriate test data must be generated for each property on an object within an object-oriented application under development. As with objects and their properties and test cases for the objects, test data for the object must evolve in conjunction with changes in the external data format around which the objects and properties are structured.
Independent of test case and test data generation, to instantiate an object for testing, object constructors typically requires several arguments which dictate how the object is constructed. Often these values are calculated at the time the constructor is invoked. Therefore, it may be difficult to determine the precise values passed on the constructor call for ascertaining how the object was to be constructed.
An additional obstacle to automatic testing of object-orient applications is that, for full function of the product, real data must be accessed. Typically, however, accessing real data requires many different components of the final product to be functioning, which may be difficult during early development when components are often not completed. Even in later development phases, the probabilities of problems downstream are increased in proportion to the number of components which need to be accessed. A "short path" which accesses test data without requiring additional components provides a great advantage in situations where use of test data is acceptable.
Complex nested data structures may also impede automatic code generation and testing in object-oriented applications. The Integrion "Gold Standard" financial data stream, in particular, contains complex nested data structures for both request and response data streams. The nesting is required due to utilization of non-unique names for fields inside the nested structures. For example, the name "AmtTg" is used twice in the balance inquiry response: once under "Available Balance" and once under "Ledger Balance". Thus, in order to identify the correct instance of "AmtTg, " the name must be nested within the field under which it is used. Where nesting adds a significant level of complexity impeding automatic code generation and testing, the non-unique naming of data items poses a problem to flattening the data.
It would be desirable, therefore, to provide mechanisms overcoming the problems described above and enabling automatic code generation and testing for object-oriented applications. It would further be advantageous if the mechanism could be used with applications requiring large, numerous, complex, and/or nested data structures within the application data stream.